omero fields optional - #87

Automated Review URLs

• Readthedocs

@will-moore small bump here to have a look at will-moore#2 to have this move forward :)

@jburel @will-moore is there a central place where the fields and possible values of the omero metadata model are documented? There's a link in the spec text but explains some fields, but not all (i.e., family, etc)

@will-moore @jburel: would you like to get this into one of the upcoming .dev versions? And if so, when would you be thinking?

I actually thought this had made it into v0.6.
So, yes. As soon as possible, thanks.

@jni is leading dev1 so I'll defer. Otherwise we can get it on a board for dev2 and discuss.

@will-moore there's a number of unresolved comments here. (log->logarithmic, removing "gamma", removing "#" from the color). Otherwise, I'm happy for this to go into 0.9.dev1 which is due ~end August. Note also that I don't have merge rights in this repo 😅 so someone else will have to do so, presumably after 0.6 is out. (Although, given the backwards compatibility of the change, I would not be opposed if it went into 0.6.rc1/final. CC @jo-mueller)

I think that is all the fixes done.
I was checking https://omero.readthedocs.io/en/stable/developers/Web/WebGateway.html#imgdata for any reference to coefficient and family but it has no info on these and actually has less info than is in these docs themselves so I've removed that link.

I also have therefore also removed the coefficient and family fields from the omero block since these have never been defined and never used AFAIK.

Great. @will-moore do you want to mark this as ready for review then?

@jo-mueller what do you think about shipping this with 0.6 final?

@jni sorry it took me so long to catch up here. To summarize:

Arguments for adding:

• Syncs spec with what was already in the schemas (i.e., label, active, inverted have been in the schemas for a while(?)), and this matches the text with them
• All changes are relaxing requirements, so non-breaking

Arguments against:

• timing?

After some more thought, since I made a quite verbal statement about no new changes in 0.6, I'm hesitant to eat from the forbidden fruit and slip in this (very reasonable!) PR 🙈

I think my headcanon for moving this forward would be:

1. Get the feedback from @jburel - I think there were some unresolved comments further up?
2. I agree that the requirements are unreasonably tight - but writers will probably circumvent this by writing some reasonable defaults, i.e., for min/max or start/end. Making these fields non-required would make these defaults a bit more opinionated as they are now. Aside from the fact that validators would need to update code.
3. Get this PR in first thing after the 0.6 tag?

related to the redo of omero fields, here is an insteesting scenario where color is being used as a local ID for a channel

https://github.com/JurgenKriel/macro_candi

Channels are resolved by colour, not index. canmac/io/channels.py reads the OME-Zarr omero metadata and matches hex colours, so channel order changes don't silently mis-assign data. Edit COLORS there for your fluorophores.

this touches on both the need of a channel spec and on different uses of the omero metadata block

Changed based branch to 0.9dev for inclusion in the 0.9.dev1